Skip to content

Introduce cf_sprite_is_valid#477

Open
pusewicz wants to merge 1 commit intoRandyGaul:masterfrom
pusewicz:cf_sprite_is_valid
Open

Introduce cf_sprite_is_valid#477
pusewicz wants to merge 1 commit intoRandyGaul:masterfrom
pusewicz:cf_sprite_is_valid

Conversation

@pusewicz
Copy link
Contributor

cf_sprite_is_valid returns a bool depending whether the checks confirm the sprite is a valid struct by comparing the ids.

`cf_sprite_is_valid` returns a `bool` depending whether the checks
confirm the sprite is a valid struct by comparing the ids.
@RandyGaul
Copy link
Owner

Hmm maybe we should just make it a macro

@pusewicz
Copy link
Contributor Author

Yeah but then macros are just... well, macros. No types, no nothing. This is technically safer, better documented, public API.

@RandyGaul
Copy link
Owner

RandyGaul commented Feb 17, 2026

I don’t really see how it’s safer and we can document a macro the same way we document anything else using docsparser. Macro would also be more performant.

Hmm macro can also work with all CF types, e.g. #define CF_IS_VALID(handle) (handle.id), and _Generic can be used to specialize the sprite path. This would work with any of the very numerous handle types throughout CF and reduce the number of different docs pages we’d have to generate if we made a function for every single different kind of handle in all of CF. It would also not be as good of an experience to have to try and remember which is_valid function you need for each different handle.

@RandyGaul
Copy link
Owner

Example: 05df187

@pusewicz
Copy link
Contributor Author

Yeah got it. I'll get back to this PR when I have time. Busy with another project. Feel free to close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants